A common method for applications to store information is by means of an external or embedded relational database (“DB”). Even if in most of the cases this is the best approach, there are some circumstances where it does not offer a real benefit, like for example:
1. The application does not need a relational DB but a hierarchical repository where the information is saved in different layers of the hierarchy. This may be because the information is identified by different IDs, that can be the element of the hierarchy, and the retrieved information performs different levels of navigation of the hierarchy.
2. The application requires a minimum footprint (also for the external application it uses).
3. The application does not need to share information with other applications.
A simple way to implement this kind of repository is to exploit the hierarchical file system available in every operating system, having a specific subtree dedicated for information storage.
Tivoli Common Reporting (TCR) is an example of a component that exploits this functionality.
The Tivoli Common Reporting data store contains the available reports, which you can search, format, and view using a web user interface. The data store organizes reports into groups called report sets, and it also contains related objects such as report designs and report snapshots.
FIG. 1 shows an example of the resulting hierarchical file structure. FIG. 1 shows an exemplary hierarchical file structure in a schematic manner similar to that commonly adopted in graphical user interfaces. As shown, the hierarchy comprises 5 levels, with the root directory 110 on the left hand side. The root directory 110 contains two sub directories 121, 122. Sub directory 121 contains sub directory 131 which in turn contains data file 141. Sub directory 122 itself contains two sub directories 132, 133. Sub directory 132 contains sub directory 142 which in turn contains data file 152. Sub directory 133 in turn contains sub directory 143 which itself contains data file 153. In the case of the present example whereby the data files 141, 152, 153 belong to the Tivoli Common Reporting component, they may comprise report designs, in files with extension .rptdesign, in the hierarchical file system where the directories are the report set and the files are the reports (.rptdesign files). For the sake of the present description, there is defined a repository comprising a subtree branching from the directory 122. Each element of the subtree has an identifier. The directories 122, 132, 133, 142, 143 have the identifiers id1, id2, id5, id3 and id6, respectively. The data files 152 and 153 have the identifiers id4 and id7, respectively. Each element in the subtree may be uniquely identified in terms of a tuple containing identifiers of the element in question, the root of the subtree and each intervening element. Thus, the data file 152 may be identified by means of the tuple {id1, id2, id3, id4}. On this basis, it is not necessary that each identifier be globally unique, but need only be unique within its own directory.
The tree structure may also be considered in terms of levels 0 to n, where 0 is the root directory, 1 is the first level of the repository containing the directory 122, level 2 is the level of directories 132 and 133, . . . , level n−1 is second lowest level in the hierarchy, which in the present example is the level containing directories 142 and 143 and n is the last level, which in the present example is the level containing data files 152 and 153 such that binary information will be saved as leaves of the tree.
A problem arising in this approach is that a malicious or clumsy user could easily change or replace the content of the files or move or delete files or directories in their entirety, without such changes being noticed, leading to unpredictable or incorrect behavior.